Add cryptographic hash chaining as tamper evidence option for C9.4.3#145
Add cryptographic hash chaining as tamper evidence option for C9.4.3#145jmanico merged 3 commits intoOWASP:mainfrom
Conversation
Extends C9.4.3 to include cryptographic hash chaining as a tamper evidence mechanism alongside append only/WORM/immutable log store. Hash chains (each record includes the hash of the prior record) provide portable tamper evidence that works with any storage backend, can be independently verified by any party, and detects tampering even if the storage layer is compromised. Reference implementation: https://github.com/mattijsmoens/sovereign-shield (CoreSafety module, SHA-256 hash chains for audit entries)
| | **9.4.1** | **Verify that** each agent instance (and orchestrator/runtime) has a unique cryptographic identity and authenticates as a first-class principal to downstream systems (no reuse of end-user credentials). | 1 | D/V | | ||
| | **9.4.2** | **Verify that** agent-initiated actions are cryptographically bound to the execution chain (chain ID) and are signed and timestamped for non-repudiation and traceability. | 2 | D/V | | ||
| | **9.4.3** | **Verify that** audit logs are tamper-evident (append-only/WORM/immutable log store) and include sufficient context to reconstruct who/what acted, initiating user identifier, delegation scope, authorization decision (policy/version), tool parameters, approvals (where applicable), and outcomes. | 2 | D/V | | ||
| | **9.4.3** | **Verify that** audit logs are tamper-evident (via append-only/WORM/immutable log store, cryptographic hash chaining where each record includes the hash of the prior record, or equivalent integrity guarantees that can be independently verified) and include sufficient context to reconstruct who/what acted, initiating user identifier, delegation scope, authorization decision (policy/version), tool parameters, approvals (where applicable), and outcomes. | 2 | D/V | |
There was a problem hiding this comment.
I think "tamper-evident" summarizes our intent of integrity guarantees. I'm not sure if we need to document such implementation detail.
Where the implementation details are not specific to AI, I would leave it to be looked up from other sources and keep it high-level; we just set this as a requirement for AI systems on certain level of security.
There was a problem hiding this comment.
That's a fair point. "Tamper-evident" does cover the intent well, and I agree the standard should stay implementation-agnostic. I could simplify the wording. Would something like "tamper-evident (via append-only storage, cryptographic chaining, or equivalent integrity guarantees that can be independently verified)" work? That keeps it high-level while acknowledging there's more than one valid approach.
Simplified wording per reviewer feedback - implementation-agnostic
|
I would like to keep away from prescriptive controls especially around logging, something already covered in ASVS. May I politely suggest: Verify that audit logs are integrity-protected and include sufficient context to reconstruct who or what acted, the initiating user identifier, delegation scope, authorization decision, tool parameters, approvals where applicable, and outcomes. or Verify that audit logs are protected against unauthorized modification and include sufficient context to reconstruct who or what acted, the initiating user identifier, delegation scope, authorization decision, tool parameters, approvals where applicable, and outcomes. .. and if this to too far from your vision please push back! |
|
Because of a duplicate I opened #222 & #322 and changed the text of 9.4.3 @ottosulin / @jmanico: What do you think? |
|
@RicoKomenda agreed with your dedup PRs good catches now the content is overall much more consistent. Both merged now. |
9.4.3 was listed twice following a merge conflict between PR OWASP#222 (which removed the generic tamper-evidence clause from 9.4.3) and PR OWASP#145 (which added cryptographic hash chaining as a tamper-evidence option by inserting a new row, not replacing the existing one). Both rows covered the same requirement. The first row (introduced by PR OWASP#145) is kept as it is the more complete version: it covers all tamper-evidence mechanisms (WORM/append-only, hash chaining, equivalent guarantees) plus all agent-specific context fields. The second row (the PR OWASP#222 remnant) was a subset and is removed.
9.4.3 was listed twice following a merge conflict between PR #222 (which removed the generic tamper-evidence clause from 9.4.3) and PR #145 (which added cryptographic hash chaining as a tamper-evidence option by inserting a new row, not replacing the existing one). Both rows covered the same requirement. The first row (introduced by PR #145) is kept as it is the more complete version: it covers all tamper-evidence mechanisms (WORM/append-only, hash chaining, equivalent guarantees) plus all agent-specific context fields. The second row (the PR #222 remnant) was a subset and is removed.
4 participants
Related to #144
Extends C9.4.3 to include cryptographic hash chaining as a tamper evidence mechanism alongside append only/WORM/immutable log store. Hash chains (each record includes the hash of the prior record) provide portable tamper evidence that works with any storage backend, can be independently verified by any party, and detects tampering even if the storage layer is compromised. Reference implementation: https://github.com/mattijsmoens/sovereign-shield (CoreSafety module, SHA-256 hash chains for audit entries)